IPAS THE lIOT NETWORK LAYER 


a 
Introduction 


e Concepts Covered: 
e Discussion on Network layer connectivity, or referred Layer 3 
» The Business Case for IP: the advantages of IP from an lol perspective and 
introduces the concepts of adoption and adaptation. 


* The Need for Optimization: the challenges of constrained nodes and devices when 
deploying IP along with migration from |IPv4 to IPv6 and how it affects lol 
networks, 


* Optimizing IP for loT: the common protocols and technologies in loT networks 
utilizing P,including 6LOWPAN, 6TISCH, and RPL 

* Profiles and Compliances: some of the most significant organizations and 
standards bodiesinvolved with IP connectivity and loT 


The Business Case for IP 


> Data flowing from or to “things” 's consumed, controlled, or 
monitored by data center servers either in the cloud or in locations 
that may be distributed or centralized. 


» The system solutions combining various physical and data link layers 

call for an architectural approach with a common layer(s) 
independent from the lower (connectivity) and/or upper 
(application) layers. That is using IP (Internet Protocol) 


The Business Case for IP 

The Key Advantages of Internet Protocol 

e In information technology (IT) or operational technology (OT), the 
lifetime of the underlying technologies and products. 


e To guarantee multi-year lifetimes is to define a layered architecture such 
as the 30-year-old IP architecture. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


° The key advantages of the IP for the Internet of Things: 
e Open and standards-based 
° Versatile 
e Ubiquitous 
° Scalable 
e Manageable and highly secure 
e Stable and resilient 
e Consumers market adoption 
e The innovation factor 


The Business Case for IP 
The Key Advantages of Internet Protocol 


» Open and standards-based 
e The Internet of Things creates a new paradigm in which devices, applications, 
and users can leverage a large set of devices and functionalities while 
guaranteeing interchangeability and interoperability, security, and management. 


e This calls for implementation, validation, and deployment of open, standards- 
based solutions. 


e While many standards development organizations (SDOs) are working on Internet 
of Things definitions, frameworks, applications, and technologies, none are 
questioning the role of the Internet Engineering Task Force (IETF) as the 
foundation for specifying and optimizing the network and transport layers. 


e The IETF is an open standards body that focuses on the development of the 
Internet Protocol suite and related Internet technologies and protocols. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


> Versatile: 


e Alarge spectrum of access technologies is available to offer connectivity of 
“things” in the last mile. 


e Even if physical and data link layers such as Ethernet, Wi-Fi, and cellular are widely 
adopted, the history of data communications demonstrates that no given wired or 
wireless technology fits all deployment criteria. 

e Communication technologies evolve at a pace faster than the expected 10- to 20- 
year lifetime of OT solutions. 

e So, the layered IP architecture is well equipped to cope with any type of physical 
and data link layers. 

e This makes IP ideal as a long-term investment because various protocols at these 
layers can be used in a deployment now and over time, without requiring changes 
to the whole solution architecture and data flow. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


° Ubiquitous: 

e All recent operating system releases, from general-purpose computers and servers 
to lightweight embedded systems (TinyOS, Contiki, and so on), have an integrated 
dual (IPv4 and IPv6) IP stack that gets enhanced over time. 

e loT application protocols in many industrial OT solutions have been updated in 
recent years to run over IP. 

e While these updates have mostly consisted of IPv4 to this point, recent 
standardization efforts in several areas are adding |Pv6. 

e Infact, IP is the most pervasive protocol when you look at what is supported 
across the various loT solutions and industry verticals. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


» Scalable: 


e As the common protocol of the Internet, IP has been massively deployed and 
tested for robust scalability. 

e Millions of private and public IP infrastructure nodes have been operational for 
years, offering strong foundations for those not familiar with IP network 
management. 

e Adding huge numbers of “things” to private and public infrastructures may 
require optimizations and design rules specific to the new devices. 

e However, you should realize that this is not very different from the recent 
evolution of voice and video endpoints integrated over IP. 


e IP has proven before that scalability is one of its strengths. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


» Manageable and highly secure: 


e Communications infrastructure require appropriate management and security 
capabilities for proper operations. 


e One of the benefits that comes from 30 years of operational IP networks is the 
well understood network management and security protocols, mechanisms, and 
toolsets that are widely available. 

e Adopting IP network management also brings an operational business 
application to OT. Well-known network and security management tools are easily 
leveraged with an IP network layer. 

e However, you should be aware that despite the secure nature of IP real 
challenges exist in this area. 

e Specifically, the industry is challenged in securing constrained nodes, handling 
legacy OT protocols, and scaling operations. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


» Stable and resilient: 
e IP has been around for 30 years, and it is clear that IP is a workable solution. 


e IP has a large and well-established knowledge base and, more importantly, it has 
been used for years in critical infrastructures, such as financial and defense 
networks. 


e In addition, IP has been deployed for critical services, such as voice and video, 
which have already transitioned from closed environments to open IP standards. 

e Finally, its stability and resiliency benefit from the large ecosystem of IT 
professionals who can help design, deploy, and operate IP-based solutions. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


» Consumers’ market adoption: 

e When developing loT solutions and products targeting the consumer market, 
vendors know that consumers’ access to applications and devices will occur 
predominantly over broadband and mobile wireless infrastructure. 

e The main consumer devices range from smart phones to tablets and PCs. The 
common protocol that links loT in the consumer space to these devices is IP. 


The Business Case for IP 
The Key Advantages of Internet Protocol 


° The innovation factor: 


e The past two decades have largely established the adoption of IP as a factor for 
increased innovation. 


e IP is the underlying protocol for applications ranging from file transfer and e-mail 
to the World Wide Web, ecommerce, social networking, mobility, and more. 


e Even the recent computing evolution from PC to mobile and mainframes to cloud 
services are perfect demonstrations of the innovative ground enabled by IP. 


e Innovations in loT can also leverage an IP underpinning. 


ee 
The Business Case for IP 


Adoption or Adaptation of the Internet Protocol 


e The use of numerous network layer protocols in addition to IP is 
often a point of contention between computer networking 
experts. Typically, one of two models, adaptation or adoption, is 
proposed: 

e Adaptation means application layered gateways (ALGs) must be 
Be mete to ensure the translation between non-IP and IP 
ayers. 

e Adoption involves replacing all non-IP layers with their IP layer 
counterparts, simplifying the deployment model and operations. 

° How to implement IP in data center, cloud services, and operation 
centers hosting loT applications. 


e Adoption of IP is more complicated and often makes running IP 
end-to-end more difficult. 


The Business Case for IP 
Adoption or Adaptation of the Internet Protocol 


e In the industrial and manufacturing sector, Solutions and product 
lifecycles many protocols have been developed for serial 
communications. 


e While IP and Ethernet support were not specified in the initial 
versions, more recent specifications for these — serial 
communications protocols integrate Ethernet and IPv4. 


e Supervisory control and data acquisition (SCADA) applications that 


operate both the IP adaptation model and the adoption model. 


e Implementations that make use of IP adaptation have SCADA 
devices attached through serial interfaces to a gateway 
tunneling or translating the traffic. 


e With the IP adoption model, SCADA devices are attached via 
Ethernet to switches and routers forwarding their IPv4 traffic. 


The Business Case for IP 
Adoption or Adaptation of the Internet Protocol 


e ZigBee that runs a non-IP stack between devices and a ZigBee 
gateway that forwards traffic to an application server. 


°A ZigBee erway often acts as a translator between the 
ZigBee and IP protocol stacks. 


e Following factors when trying to determine which model is best 
suited for IP connectivity: 
Bidirectional versus unidirectional data flow 
e Overhead for last-mile communications paths 
e Data flow model 
e Network diversity 


a 
The Business Case for IP 


Adoption or Adaptation of the Internet Protocol 
» Bidirectional versus unidirectional data flow 
e While bidirectional communications are generally expected, 
some last-mile technologies offer optimization for unidirectional 
communication. 


° e.g. RFC 7228, may only infrequently need to report a few bytes 
of data to an application LPWA technologies, include fire alarms 
sending alerts or daily test reports, electrical switches being 
pushed on or off, and water or gas meters sending weekly 
indexes. 


» For these cases, it is not necessarily worth implementing a full IP 
stack. 


The Business Case for IP 


Adoption or Adaptation of the Internet Protocol 
» Overhead for last-mile communications paths: 
e IP adoption implies a layered architecture with a per-packet 
overhead that varies depending on the IP version. 
e IPv4 has 20 bytes, IPv6 has 40 bytes, UDP has 8 bytes and TCP has a 
minimum of 20 bytes 
e If the data to be forwarded by a device is infrequent and only a few 
bytes, you can potentially have more header overhead than device 
data again, (in the case of LPWA technologies). 
e Consequently, you need to decide whether the IP adoption model is 
necessary and, if it is, how it can be optimized. 
e This same consideration applies to control plane traffic that is run over IP for 
low-bandwidth, last-mile links. 
e Routing protocol and other verbose network services may either not be 
required or call for optimization. 


The Business Case for IP 
Adoption or Adaptation of the Internet Protocol 
- Data flow model: 


» One benefit of the IP adoption model is the end-to-end nature of 
communications. 

» Any node can easily exchange data with any other node in a network, although 
secuniy, privacy, and other factors may put controls and limits on the “end-to- 
end” concept. 

» However, in many loT solutions, 

» a device's data flow Is limited to one or two applications. 

» In this case, the adaptation model can work because translation of traffic needs 
to occur only between the end device and one or two application servers. 

> Depending on the network topology and the data flow needed, both IP 
adaptation and adoption models have roles to play in last-mile 
connectivity. 


The Business Case for IP 


Adoption or Adaptation of the Internet Protocol 


» Network diversity: 
- One of the drawbacks of the adaptation model is a general 
dependency on single PHY and MAC layers. 
» For example, ZigBee devices must only be deployed in ZigBee network islands. 
- Therefore, a deployment must consider which applications have to 
run on the gateway connecting these islands and the rest of the 
world. 


- Integration and coexistence of new physical and MAC layers or new 
applications impact how deployment and operations have to be 
planned. 


- This is not a relevant consideration for the adoption model. 
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The Need for Optimization 


e Internet of Things will largely be built on the Internet Protocol suite 


e In coping with the integration of non-IP devices, may need to deal with 
the limits at the device and network levels that loT often imposes. 
e Therefore, optimizations are needed at various layers of the IP stack to 
handle the restrictions that are present in loT networks. 
e The following concepts take a detailed look at why optimization is 
necessary for IP. 
e Constrained Nodes 
e Constrained Networks 
e IP Versions 


The Need for Optimization: Constrained Nodes 


e loT having different classes of devices coexist. 


e Depending on its functions in a network, a “thing” architecture may or 
may not offer similar characteristics compared to a generic PC or server in 
an IT environment. 


e Another limit is that this network protocol stack on an loT node may be 
required to communicate through an unreliable path. 

e Even if a full IP stack is available on the node, this causes problems such as 
limited or unpredictable throughput and low convergence when a topology 
change occurs. 

e Power consumption is a key characteristic of constrained nodes. 

e Battery Enabled with life soan of Months to 10 years 

e Battery-powered nodes impact communication intervals. 


e The Node one that is “always on” instead another option is “always off,” 
which means communications are enabled only when needed to send data. 


as 
The Need for Optimization Constrained Nodes 


e lol constrained nodes can be classified as follows: 


» Devices that are very constrained in resources, may communicate infrequently to 
transmit a few bytes, and may have limited security and management capabilities: 
This drives the need for the IP adaptation model, where nodes communicate 
through gateways and proxies. 


Devices with enough power and capacities to implement a stripped- down IP stack 
or non-IP stack: In this case, you may implement either an optimized IP stack and 
directly communicate with application servers (adoption model) or go for an IP or 
non-IP stack and communicate through gateways and proxies (adaptation model). 


Devices that are similar to generic PCs in terms of computing and power resources 
but have constrained networking capacities, such as bandwidth: These nodes 
usually implement a full IP stack (adoption model), but network design and 
application behaviors must cope with the bandwidth constraints. 


The Need for Optimization Constrained Nodes 


- In constrained nodes, the costs of computing power, memory, 
storage resources, and power consumption are generally 
decreasing. 

- At the same time, networking technologies continue to improve 
and offer more bandwidth and reliability. 


The Need for Optimization Constrained Networks 


e Low-speed connections (like low-speed modems) demonstrated that IP 
could run over low-bandwidth networks. 


e High-speed connections are not usable by some loT devices in the last 
mile. 

- The reasons include the implementation of technologies with low 
bandwidth, limited distance and bandwidth due to regulated transmit 
power, and lack of or limited network services. 

- A constrained network can have high latency and a high potential for 
packet loss. 

» Constrained networks are often referred to as low-power and lossy 
networks (LLNs). 

- Constrained networks operate between a few kbps and a few hundred 
Kops and may utilize a star, mesh, or combined network topologies, 
ensuring proper operations 
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The Need for Optimization Constrained Networks 


e In constrained network, it is not unusual for the packet delivery rate 
(PDR) to oscillate between low and high percentages. 

e Large bursts of unpredictable errors and even loss of connectivity at times may 
occur, where packet delivery variation may fluctuate greatly during the 
course of a day. 

e Latency and control plane reactivity: 

> One of the golden rules in a constrained network is to “underreact to failure.” 
- Due to the low bandwidth, a constrained network that overreacts can lead to a 
network collapse which makes the existing problem worse. 

e Control plane traffic must also be kept at a minimum; otherwise, it consumes 
the bandwidth that is needed by the data traffic. 

e The power consumption in battery-powered nodes 

» Any failure or verbose control plane protocol may reduce the lifetime of the 
batteries. 

° This led to work on optimizing protocols for loT 


The Need for Optimization IP Versions 


- IETF has been working on transitioning the Internet from IP 
version 4 to IP version 6. 

- The main driving force has been the lack of address space in 
IPv4 as the Internet has grown. 

- IPv6 has a much larger range of addresses that should not be 
exhausted for the foreseeable future. 

» Today, both versions of IP run over the Internet, but most traffic is 
still IPv4 based. 

> Internet of Things has the Internet itself and support both |Pv4 
and IPv6 versions concurrently. 


» Techniques such as tunneling and translation need to be employed in lol 
solutions to ensure interoperability between |Pv4 and IPv6. 


The Need for Optimization IP Versions 


- The following are some of the main factors applicable to IPv4 and 
IPV6 support in an loT solution: 
> Application Protocol 
» Cellular Provider and Technology 
» Serial Communications 
- IPv6 Adaptation Layer 


- Application Protocol: lol devices implementing Ethemet or Wi-Fi 
interfaces can communicate over both |IPv4 and IPv6, but the 
application protocol may dictate the choice of the IP version. 

» Forexample, SCADAprotocols suchas DNP3/IP (EEE1815), Modbus TCPor the IEC 
60870-5-104 standards are specified only for |IPv4. 

> So, there are no known production implementations by vendors of these protocols 
over |IPv6 today. 

> For loT devices with Slee protocols defined by the IETF suchas HTTP/HTTPS, 
CoAP MQTT and XMPP both IP versions are supported. 

- The selection of the IP version is only dependent on the implementation. 


The Need for Optimization IP Versions 


- Cellular Provider and Technology: lol devices with cellular 
modems are dependent on the generation of the cellular 
technology as well as the data services offered by the provider. 


- For the first three generations of data services GPRS, Edge, and 3G |Pv4 is 
the base protocol version. 

» Consequently, if IPv6 is used with these generations, it must be tunneled 
over |IPv4. 


> On 4G/LTE networks, data services can use |IPv4 or IPv6 as a base 
protocol, depending on the provider. 


The Need for Optimization IP Versions 


» Serial Communications: 


» Data is transferred using either proprietary or standards-based protocols, 
such as DNP3, Modbus, or IEC 60870-5-101. 


- In the past, communicating this serial data over any sort of distance could 
be handled by an analog modem connection. 


» However, as service provider support for analog line services has declined, the 
solution for communicating with these legacy devices has been to use local 
connections. To make this work, you connect the serial port of the legacy device 
to a nearby serial port on a piece of communications equipment, typically a 
router. This local router then forwards the serial traffic over IP to the central 
server for processing. 


» Encapsulation of serial protocols over IP leverages mechanisms such as raw 
socket TCP or UDP. While raw socket sessions can run over both |Pv4 and IPv6, 
current implementations are mostly available for IPv4 only. 


The Need for Optimization IP Versions 


- IPv6 Adaptation Layer: 
e IPv6-only adaptation layers for some physical and data link layers for 
recently standardized loT protocols support only IPv6. 


e While the most common physical and data link layers (Ethernet, Wi-Fi, 
and so on) stipulate adaptation layers for both versions, newer 
technologies, 

e such as IEEE 802.15.4 (Wireless Personal Area Network), IEEE 1901.2, and 
ITU G.9903 (Narrowband Power Line Communications) only have an |IPv6 
adaptation layer specified. 

e This means that any device implementing a technology that requires an 
IPv6 adaptation layer must communicate over an |Pv6-only subnetwork. 

e This is reinforced by the IETF routing protocol for LLNs, RPL, which is IPv6 
only. 


| 
Optimizing IP for loT 


> While the Internet Protocol is key for a successful Internet of 
Things, constrained nodes and constrained networks mandate 
optimization at various layers and on multiple protocols of the IP 
architecture 


Transport 

Layer TCP/UDP 
Network 

Layer | IPv6/IPv4 


—— 


Data Link 7 
Layer Including 802.14.4g, 802.15.4e 
gna Wired/Wireless 


Figure 5-1 Optimizing IP for loT Using an Adaptation Layer 
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Optimizing IP for loT 


° The following optimizations technique of IP already available: 
e From 6LOWPAN to 6Lo 
e Header Compression 
e Fragmentation 
e Mesh Addressing 
e Mesh-Under Versus Mesh-Over Routing 
e 6Lo Working Group 
e 6TISCH 
e RPL 
e Objective Function (OF) 
e Rank 
e RPL Headers 
e Metrics 
e Authentication and Encryption on Constrained Nodes 
e ACE 
e DICE 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


e Inthe IP architecture, the transport of IP packets over any given Layer 
1 (PHY) and Layer 2 (MAC) protocol must be defined. 

e The initial focus of the 6LoWPAN working group was to optimize the 
transmission of IPv6 packets over constrained networks such as IEEE 
802.15.4. 


Optimizing IP for loT From 6LOWPAN to 6Lo 


loT Protocol Stack with 
IP Protocol Stack 6LOWPAN Adaptation Layer 


Application Application Protcols 


Transport ICMP 
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Figure 5-2 Comparison of an IoT Protocol Stack Utilizing 6LoWPAN and an IP 
Protocol Stack 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


e The 6LOWPAN working group published several RFCs (Request for 
Comments by IETF), but RFC defines frame headers for the capabilities 
of 

e Header compression, 
e Fragmentation, 
e Mesh addressing. 


Optimizing IP for loT From 6LOWPAN to 6Lo 
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Figure 5-3 6LoWPAN Header Stacks 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


» Header Compression: 
e Shrinks the size of IPv6’s 40-byte headers and User Datagram Protocol's 
(UDP’s) 8-byte headers down as low as 6 bytes combined in some 
cases. 


e Header compression for 6LOWPAN is only defined for an IPv6 header 
and not for |IPv4. 


e However, a number of factors affect the amount of compression, such as 
implementation of RFC, whether UDP is included, and various IPv6 addressing 
scenarios. 

e 6LOWPAN works by taking advantage of shared information known by 
all nodes from their participation in the local network. 


e In addition, it omits some standard header fields by assuming 
commonly used values. 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


6LOWPAN Without Header Compression 
127 Byte IEEE 802.15.4 Frame 
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6LOWPAN With IPv6 and UDP Header Compression 
127 Byte IEEE 802.15.4 Frame 


6LOWPAN Header 
with Compressed 
IPv6 Header 
Figure 5-4 6LoWPAN Header Compression 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


- At the top of, a 6LOWPAN frame without any header 
compression enabled: 

° The full 40-byte IPv6 header and 8-byte UDP header are visible. 

e The 6LOWPAN header is only a single byte in this case. 

e Uncompressed IPv6 and UDP headers leave only 53 bytes of data payload 
out of the 127-byte maximum frame size in the case of IEEE 802.15.4. 
>The bottom half of shows a frame where header 

compression enabled: 

e The 6LOWPAN header increases to 2 bytes to accommodate the 
compressed IPv6 header, and UDP has been reduced in half, to 4 bytes 
from 8. 

e Most importantly, the header compression has allowed the payload to 
more than double, from 53 bytes to 108 bytes, which is obviously much 
more efficient. 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


> Fragmentation: 

e The maximum transmission unit (MTU) for an IPv6 network must be at 
least 1280 bytes. 

e The term MTU defines the size of the largest protocol data unit that can 
be passed. 

e For IEEE 802.15.4, 127 bytes is the MTU. 

e A problem because of IPv6, with a much larger MTU, is carried inside the 
802.15.4 frame with a much smaller one. 


° To remedy this situation, large IPv6 packets must be fragmented across 
multiple 802.15.4 frames at Layer 2. 


Optimizing IP for loT From 6LOWPAN to 6Lo 


6LOWPAN Fragmentation Header 
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Figure 5-5 6LoWPAN Fragmentation Header 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


° The fragment header utilized by 6LOWPAN is composed of three 
primary fields: 
e Datagram Size: The 1-byte field specifies the total size of the 
unfragmented payload 
e Datagram Tag: identifies the set of fragments for a payload. 
e Datagram Offset: field delineates how far into a payload a particular 
fragment occurs. 


° The 6LOWPAN fragmentation header field itself uses a unique bit value to 
identify that the subsequent fields behind it are fragment fields as 
opposed to another capability, such as header compression. 

e Inthe first fragment, the Datagram Offset field is not present because 
it would simply be set to 0. 


° This results in the first fragmentation header for an IPv6 payload being 
only 4 bytes long. 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


» Mesh Addressing: 


e The purpose of the 6LOWPAN mesh addressing function is to 
forward packets over multiple hops. 


e Three fields are defined for this header: 


e Hop Limit: The hop limit for mesh addressing also provides an 
upper limit on how many times the frame can be forwarded. 
Each hop decrements this value by 1 as it is forwarded. Once 
the value hits 0, it is dropped and no longer forwarded. 

e Source Address, and Destination Address: The Source Address 
and Destination Addressfields for mesh addressing are IEEE 
802.15.4 addresses indicating the endpoints of an IP hop. 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


6LOWPAN Mesh Addressing Header 
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Figure 5-6 6LoWPAN Mesh Addressing Header 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


» Mesh-Under Versus Mesh-Over Routing: 

e IEEE 802.15.4, IEEE 802.15.4g, and IEEE 1901.2a that support mesh 
topologies and operate at the physical and data link layers, two 
main options exist for establishing reachability and forwarding 
packets. 

> “Mesh-under”: the routing of packets is handled at the 
6LOWPAN adaptation layer. 

> “Mesh-over” or “route-over”: utilizes IP routing for getting 
packets to their destination. 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


e Mesh-under routing, 


e the routing of IP packets leverages the 6LOWPAN mesh addressing 
header to route and forward packets at the link layer. 
e The term mesh-under is used because multiple link layer hops can be 
used to complete a single IP hop. 
e Nodes have a Layer 2 forwarding table that they consult to route the 
packets to their final destination within the mesh. 
e An edge gateway terminates the mesh-under domain. 
° The edge gateway must also implement a mechanism to translate 
between the configured Layer 2 protocol and any IP routing 
mechanism implemented on other Layer 3 IP interfaces. 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


e Mesh-over or route-over scenarios, 

e IP Layer 3 routing is utilized for computing reachability and then getting 
packets forwarded to their destination, either inside or outside the mesh 
domain. 

e Each full-functioning node acts as an IP router, so each link layer hop is an 
IP hop. 

e When a LoWPAN has been implemented using different link layer 
technologies, a mesh-over routing setup is useful. 

e While traditional IP routing protocols can be used, a specialized routing 
protocol for smart objects, such as RPL 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


» 6Lo Working Group: 

e The 6Lo working group seeks to expand on this completed work 
with a focus on IPv6 connectivity over constrained node 
networks. 


e While the 6LOWPAN working group initially focused its optimizations 
on IEEE 802.15.4 LLNs, 
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Optimizing IP for loT From 6LOWPAN to 6Lo 


» 6Lo working group is focused on the following: 
- IPv6-over-foo adaptation layer specifications using 6LOWPAN technologies (RFC4944, 
RFC6282, RFC6775) for link layer technologies: 
For example, this includes: 
» IPv6 over Biuetooth Low Erergy 
- Transmission of IPv6 packets over near-field communication 
> IPv6 over 802.11ah 
» Transmission of IPv6 packets over DECT Ultra Low Energy 
- Transmission of IPv6 packets on WIA-PA (Wireless Networks for Industrial Automation—Process 
Automation) 
» Transmission of IPv6 over Master Slave/Token Passing (MS/TP) 
- Information and data models such as MIB modules: 
» One example is R°C7388, “Definition of Managed Objects for IPv6 over Low-Power Wireless 
Personal Area Networks (6LoW FANs).” 
» Optimizations that are applicable to more than one adaptation layer specification: 
- Forexample, this includes RFC 7400, “6LOWPAN-GHC: Generic Header Compression for IPv6 over 
Low-Power Wireless Personal Area Networks (6LOWPANs).” 
» Informational and maintenance publications needed for the IETF specifications in this 
area 


Optimizing IP for loT 6TISCH 


> IEEE 802.15.4e, Time-Slotted Channel Hopping (TSCH), is an add-on 
to the Media Access Control (MAC) portion of the IEEE 802.15.4 
standard Devices implementing IEEE 802.15.4e 
» TSCH communicate by following a Time Division Multiple Access 
(TDMA) schedule. 
e An allocation of a unit of bandwidth or time slot is scheduled 
between neighbor nodes. 
° This allows the programming of predictable transmissions and 
enables deterministic, industrial-type applications. 
e Not like other IEEE 802.15.4 
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Optimizing IP for loT 6TISCH 


e To standardize IPv6 over the TSCH mode of IEEE 802.15.4e (known 
as 6TISCH) 

e The IEEE 802.15.4e standard defines a time slot structure, but it 
does not mandate a scheduling algorithm for how the time slots are 
utilized. 


© This is left to higher-level protocols like 6TISCH. 


° Scheduling is critical because it can affect throughput, latency, and 
power consumption. 
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Optimizing IP for loT 6TISCH 
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» Schedules in 6TISCH are broken down into cells. 


» Acell is simply a single element in the TSCH schedule that can be allocated 
for unidirectional or bidirectional communications between specific 
nodes. 


> Nodes only transmit when the schedule dictates that their cell is open for 
communication. 


e The 6TISCH architecture defines four schedule management 
mechanisms: 
» Static scheduling 
> Neighbor-to-neighbor scheduling 
» Remote monitoring and scheduling management 


> Hop-by-hop scheduling 
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> Static scheduling: 
» All nodes in the constrained network share a fixed schedule. 
» Cells are shared, and nodes contend for slot access in a slotted aloha manner. 
» Slotted aloha is a basic protocol for sending data using time slot boundaries when 
communicating over a shared medium. 
» Static scheduling is a simple scheduling mechanism that can be used upon 
initial implementation or as a fall back in the case of network malfunction. 
» The drawback with static scheduling is that nodes may expect a packet at any 
cell in the schedule. 
> Therefore, energy is wasted idly listening across all cells. 
> Neighbor-to-neighbor scheduling: 
> Aschedule is established that correlates with the observed number of 
transmissions between nodes. 
° Cells in this schedule can be added or deleted as traffic requirements and 
bandwidth needs change. 
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» Remote monitoring and scheduling management: 

» Time slots and other resource allocation are handled by a management 
entity that can be multiple hops away. 

> The scheduling mechanism leverages 6top and even CoAP in some 
scenarios. 

> This scheduling mechanism provides quite a bit of flexibility and control 
in allocating cells for communication between nodes. 

» Hop-by-hop scheduling: 

> Anode reserves a path to a destination node multiple hops away by 
requesting the allocation of cells in a schedule at each intermediate 
node hop in the path. 


> The protocol that is used by a node to trigger this scheduling mechanism 
is not defined at this point. 
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eln addition to schedule management functions, the 6TiISCH 
architecture also defines three different forwarding models. 

e Forwarding is the operation performed on each packet by a node 
that allows it to be delivered to a next hop or an upper- layer 
protocol. 


e The forwarding decision is based on a pre existing state that was 
learned from a routing computation. 
e There are three 6TISCH forwarding models: 
e Track Forwarding (TF) 
e Fragment forwarding (FF) 
e IPv6 Forwarding (6F) 
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> Track Forwarding (TF): 
° This is the simplest and fastest forwarding model. 
e A “track” in this model is a unidirectional path between a source and a 
destination. 


This track is constructed by pairing bundles of receive cells in a schedule 
with a bundle of receive cells set to transmit. So, a frame received within a 
particular cell or cell bundle is switched to another cell or cell bundle. 


e This forwarding occurs regardless of the network layer protocol. 
> IPv6 Forwarding (6F): 
e This model forwards traffic based on its IPv6 routing table. 


e Flows of packets should be prioritized by traditional QoS (quality of 
service) and RED (random early detection) operations. 


° QOS is a classification scheme for flows based on their priority, and RED is a 
common congestion avoidance mechanism. 
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> Fragment forwarding (FF): 

e This model takes advantage of 6LOWPAN fragmentation to build a Layer 2 
forwarding table. 

e Fragmentation within the 6LOWPAN protocol. 

e IPv6 packets can get fragmented at the 6LOWPAN sublayer to handle the 
differences between IEEE 802.15.4 payload size and IPv6 MTU. 

e Additional headers for RPL source route information can further contribute to the 
need for fragmentation. 

e However, with FF, a mechanism is defined where the first fragment is routed 
based on the IPv6 header present. 


e The 6LOWPAN sublayer learns the next-hop selection of this first fragment, 
which is then applied to all subsequent fragments of that packet. Otherwise, IPv6 
packets undergo hop-by-hop reassembly. 

e This increases latency and can be power- and CPU-intensive for a constrained 
node. 
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e IETF chartered the RoLL (Routing over Low-Power and Lossy Networks) 
working group to evaluate all Layer 3 IP routing protocols and determine 
the needs and requirements for developing a routing solution for IP smart 
objects. 


e The new routing protocol should be developed for use by IP smart objects 
is IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). 


e Inan RPL network, 
° each node acts as a router and becomes part of a mesh network. 
e Routing is performed at the IP layer. 


e Each node examines every received IPv6 packet and determines the next- 
hop destination based on the information contained in the IPv6 header. 
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e The constraints of computing and memory that are common 
characteristics of constrained nodes, the protocol defines two 
modes: 


- Storing mode: 


e All nodes contain the full routing table of the RPL domain. Every node knows 
how to directly reach every other node. 


> Non-storing mode: 
e Only the border router(s) of the RPL domain contain(s) the full routing table. 


e All other nodes in the domain only maintain their list of parents and use this as 
a list of default routes toward the border router. 


° This abbreviated routing table saves memory space and CPU. 


e When communicating in non-storing mode, a node always forwards its packets 
to the border router, which knows how to ultimately reach the final destination. 
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e RPL is based on the concept of a directed acyclic graph (DAG). 
A DAG is a directed graph where no cycles exist. This means 
that from any vertex or point in the graph, you cannot follow 
an edge or a line back to this same point. All of the edges are 
arranged in paths oriented toward and terminating at one or 
more root nodes. 


Figure 5-8 Example of a Directed Acyclic Graph (DAG) 
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° A basic RPL process involves building a destination-oriented directed 
acyclic graph (DODAG). 
° ADODAG is a DAG rooted to one destination. 


e In RPL, this destination occurs at a border router known as the DODAG 
root. 


° Observe that that a DAG has multiple roots, whereas the DODAG has just 


° one. YX. DAG Roots 
DODAG 


ae 5-9 DAG and DODAG Comparison 
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e Ina DODAG, each node maintains up to three parents that provide 
a path to the root. 

° one of these parents is the preferred parent, which means it is the 
preferred next hop for upward routes toward the root. 

e The routing graph created by the set of DODAG parents across all 
nodes defines the full set of upward routes. 

e RPL protocol implementation should ensure that routes are loop 
free by disallowing nodes from selected DODAG parents that are 
positioned further away from the border router. 

» Upward routes in RPL are discovered and configured using DAG 
Information Object (DIO) messages. 


e Nodes listen to DIOs to handle changes in the topology that can affect 
routing. 
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e Nodes establish downward routes by advertising their parent set toward the 
DODAG root using a Destination Advertisement Object (DAO) message. 
eDAO messages allow nodes to inform their parents of their presence and 
reachability to descendants. 
e In non-storing mode of RPL, 
° nodes sending DAO messages report their parent sets directly to the DODAG root 
(border router), and only the root stores the routing information. 
e In storing mode, 

e each node keeps track of the routing information that is advertised in the DAO 
messages. 

e While this is more power- and CPU-intensive for each node, the benefit is that 
packets can take shorter paths between destinations in the mesh. 

e The nodes can make their own routing decisions; in non-storing mode, on the 
other hand, all packets must go up to the root to get a route for moving 
downstream. 

e RPL messages, such as DIO and DAO, run on top of IPv6. These messages 
exchange and advertise downstream and upstream routing information 
between a border router and the nodes under it. 
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DAO and DIO messages 
travel both up and down 
the DODAG depending 
on the message type. 


Figure 5-10 RPL Overview 
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» Objective Function (OF) : 
» An objective function (OF) defines how metrics are used to select routes and 
establish a node’s rank. 
» Forexample, nodes implementing an OF with Minimum Expected Number of 
Transmissions (MIETX) advertise the METXamong their parents in DIO messages. 
» Whenever a node establishes its rank, it simply sets the rank to the current 
minimum METX among its parents. 
> Rank 
» Therank isa rough approximation of how “close” a node isto the root and 
helps avoid routing loops and the count-to-infinity problem. 
» Nodes can only increase their rank when receiving a DIO message with a 
larger version number. 


» However, nodes may decrease their rank whenever they have established 
lower-cost routes. 


» While the rank and routing metrics are closely related, the rank differs from 
routing metrics in that it is used as a constraint to prevent routing loops. 
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- RPL Headers: 
e An |Pv6 Routing Header for Source Routes with the Routing Protocol for 
Low-Power and Lossy Networks (RPL). 
e Anew IPv6 option, known as the RLoption 
- The RLoption is carried in the IPv6 Hop-by-Hop header. 


- The purpose of this header is to leverage data plane packets for loop 
detection in a RPL instance. 


e Source Routing Header (SRH) for use between RPFLrouters. 
e A border router or DODAG root inserts the SRH when specifying a 


source route to deliver datagrams to nodes downstream in the mesh 
network. 
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- Metrics 

- Some of the AFL routing metrics and constraints defined in RFC 6551 include 
the following: 

» Expected Transmission Count (ETX): 


» Assigns a discrete value to the number of transmissions a node expects to make to 
deliver a packet. 


» Hop Count: 
> Tracks the number of nodes traversed in a path. Typically, a path with a lower hop 
count is chosen over a path with a higher hop count. 
> Latency: 
- Varies depending on power conservation. Paths with a lower latency are preferred. 
> Link Quality Level: 
» Measures the reliability of a link by taking into account packet error rates caused by 
factors such as signal attenuation and interference. 


» Link Color: 


- Allows manual influence of routing by administratively setting values to make a link 
more or less desirable. These values can be either statically or dynamically adjusted for 
specific traffic types. 
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» Node State and Attribute: 


- Identifies nodes that function as traffic aggregators and nodes that are 
being impacted by high workloads. High workloads could be indicative of 
nodes that have incurred high CPU or low memory states. Naturally, nodes 
that are aggregators are preferred over nodes experiencing high 
workloads. 


> Node Energy: 


» Avoids nodes with low power, so a battery-powered node that is running 
out of energy can be avoided and the life of that node and the network 
can be prolonged. 


> Throughput: 


» Provides the amount of throughput for a node link. Often, nodes conserving 
power use lower throughput. This metric allows the prioritization of paths 
with higher throughput. 


Optimizing IP for loT 
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> The IETF working groups that are focused on loT security: 
- ACE and DICE 


Optimizing IP for loT 
Authentication and Encryption on Constrained Nodes 
> ACE: 
- The Authentication and Authorization for Constrained Environments 
(ACE) working group is tasked with evaluating the applicability of existing 


authentication and authorization protocols and documenting their suitability 
for certain constrained-environment use cases. 

» ACE working group will focus its work on CoAP with the Datagram 
Transport Layer Security (DTLS) protocol. 

> The ACE working group expects to produce a standardized solution for 
authentication and authorization that enables authorized access (Get, Put, 
Post, Delete) to resources identified by a URI and hosted on a resource 
server in constrained environments. 


- Anunconstrained authorization server performs mediation of the access. 
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Authentication and Encryption on Constrained Nodes 
> DICE: 


> New generations of constrained nodes implementing an IP stack over 
constrained access networks are expected to run an optimized IP protocol 
stack. 


- The DILS in Constrained Environments (DICE) working group focuses on 
implementing the DILS transport layer security protocol in these 
environments. 

- The first task of the DICE working group is to define an optimized DILS 
profile for constrained nodes. 

> In addition, the DICE working group is considering the applicability of the 
DILS record layer to secure multicast messages and investigating how the 
DTLShandshake in constrained environments can get optimized. 


Profiles and Compliances 


Profile definitions, certifications, and promotion by alliances can help 
implementers develop solutions that guarantee interoperability 
and/or interchangeability of devices. 

e Some of the main industry organizations working on profile 
definitions and certifications for lol constrained nodes and 
networks. 

» Internet Protocol for Smart Objects (IPSO) Alliance 
> WI-SUN Alliance 

» Thread 

> IPv6 Ready Logo 


Profilesand Compliances 

Internet Protocol for Smart Objects (IPSO) Alliance 

> The alliance initially focused on promoting IP as the premier 
solution for smart objects communications. 


- Today, it is more focused on how to use IP with the IPSO Alliance 
organizing interoperability tests between alliance members to 
validate that IP for smart objects can work together and 
properly implement industry standards. 


Profilesand Compliances Wi- 


SUN Alliance 


- WiSUN's main focus is on the EEE 802.15.4g protocol and its 
support for multiservice and secure IPv6 communications with 
applications running over the UDP transport layer. 

- The utilities industry is the main area of focus for the Wi-SUN 
Alliance. 

> The Wi-SUN field area network (FAN) profile enables smart 
utility networks to provide resilient, secure, and cost-effective 
connectivity with extremely good coverage in a range of 
topographic environments, from dense urban neighborhoods to 
rural areas. 


Profiles and Compliances 
Thread 


» Thread Group has defined an |Pv6-based wireless profile that 
provides the best way to connect more than 250 devices into a 
low-power, wireless mesn network. 


Profilesand Compliances |Pv6 
Ready logo 


- The IPV6 Ready Logo program has established conformance and 
interoperability testing programs with the intent of increasing 
user confidence wnen implementing |Pv6. 


- The IPv6 Core and specific IPv6 components, such as DHCP IPsec, 
and customer edge router certifications, are in place. 


APPUCATION PROTOCOIS FOR 
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a 
Introduction 


- Concepts covered about the higher-layer lol protocols 
> The Transport Layer: 

- IP-based networks use either TCP or UDP However, the constrained nature of loT 
networks requires a closer look at the use of these traditional transport 
mechanisms. 

> loT Application Transport Methods: 


- The various types of lol application data and the ways this data can be carried 
across a network. 
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- The selection of a protocol for the transport layer as supported 
by the TCP/IP architecture in the context of loT networks. 


> With the TCP/IP protocol, two main protocols are specified for 
the transport layer: 


- Transmission Control Protocol (TCP): 
» This connection-oriented protocol requires a session to get established between 
the source and destination before exchanging data. 
» User Datagram Protocol (UDP): 


» With this connectionless protocol, data canbe quickly sentbetween source and 
destination but with no guarantee of delivery. 
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» TCP is the main protocol used at the transport layer. 
- This is largely due to tts inherent characteristics, such as its ability to transport large 
volumes of data into smaller sets of packets. 
> In addition, it ensures reassembly in a correct sequence, flow control and window 
adjustment, and retransmssion of lost packets 
- These benefits occur with the cost of overhead per packet and per session, potentially 
impacting overall packet per second performances and latency. 
- UDP 
- is most often used in the context of network services, such as Domain Name System 
(DNS), Network Time Protocol (NTP), Simple Network Management Protocol (SNMP), 
and Dynamic Host Control Protocol (DHCP), or for real-time data traffic, including voice 
and video over IP 
- In these cases, performance and latency are more important than packet retransmissions 
because re-sending a lost voice or video packet does not add value. 
» When the reception of packets must be guaranteed error free, the application layer 
protocol takes care of that function. 


» When considering the choice of a transport layer by a given lol application 
layer protocol, it is recommended to evaluate the impact of this choice on 
both the lower and upper layers of the stack. 
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- Because of constrained nodes and network need to use new lol 
application protocol, such as Constrained Application Protocol 
(CoAP), almost always uses UDP and why implementations of 
industrial application layer protocols may call for the 
optimization and adoption of the UDP transport layer if run over 


» Select TCP for cellular networks because these networks are typically more 
robust and can handle the overhead. 


- For LLNs, where both the devices and network itself are usually 
constrained, UDP is a better choice and often mandatory. 

- T@P and UDP are the two main choices at the transport layer for 
the TCP/P protocol. The performance and scalability of loT 
constrained devices and networks Is impacted by which one of 
these is selected. 
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- Concepis Covered: 
» Application Layer Protocol Not Present 
» SCADA 
> ALittle Background on SCADA 
» Adapting SCADA for IP 
> Tunneling Legacy SCADA over IP Networks 
» SCADA Protocol Translation 
> SCADA Transport over LLNs with MAP-T 
» Generic Web-Based Protocols 
- lol Application Layer Protocols 
> CoAP 
» Message Queuing Telemetry Transport (MQTT) 
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e The following categories of lol application protocols and their transport 
methods: 


- Application layer protocol not present: 
- Inthis case, the data payload isdirectly transported ontop of the lower layers. No 
application layer protocol is used. 
» Supervisory control and data acquisition (SCADA): 
» SCADA is one of the most common industrial protocols in the world, but it was 
developed long before the days of IP,and it has been adapted for IP networks. 
» Generic web-based protocols: 
» Generic protocols, suchas Ethernet, Wi-Fi, and 4G/LTE, are found on many consumer- 
and enterprise-class loT devices that communicate over non-constrained networks. 
- loT application layer protocols: 


- lol application layer protocols are devised to run on constrained nodes with a small 
compute footprint and are well adapted to the network bandwidth constraints on 
cellular or satellite links or constrained GLOWPAN networks. Message Queuing Telemetry 
Transport (MQTT) and Constrained Application Protocol (CoAP), are two well-known 
examples of loT application layer protocols. 


lol Application Transport Methods 
Application Layer Protocol Not Present 


- In Class 0 send or receive only a few bytes of data. 


» For many reasons, such as processing capability, power constraints, and cost, 
these devices do not implement a fully structured network protocol stack, such 
as IPTCPor UDPor even an application layer protocol. 


» Class 0 devices are usually simple smart objects that are severely constrained. 
> Implementing a robust protocol stack is usually not useful and sometimes not 
even possible with the limited available resources. 
» While many constrained devices, such as sensors and actuators, have 
adopted deployments that have no application layer, this 
transportation method has not been standardized. 


» This lack of standardization makes it difficult for generic implementations of 
this transport method to be successful from an interoperability perspective. 


- Eg. Different kinds of temperature sensors from different manufacturers. These 
sensors will report temperature data in varying formats. 


- The solution to this problem is to use an loT data broker 
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Figure 6-1 IoT Data Broker 
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Application Layer Protocol Not Present 

- An lol data broker is a piece of middleware that standardizes 
sensor output into a common format that can then be retrieved 
by authorized applications. 

- In figure Sensors X, Y , and Z are all temperature sensors, but 
their output is encoded differently. 

> The lol data broker understands the different formats in which 
the temperature is encoded and is therefore able to decode this 
data into a common, standardized format. 

- Applications A, B, and C in Figure can access this temperature 


data without having to deal with decoding multiple temperature 
data formats. 
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» Supervisory control and data acquisition (SCADA). 


- Designed decades ago, SCADA is an automation control system 
that was initially implemented without IP over serial links (Such as 
RS-232 and RS-485), before being adapted to Ethemet and 
IPv4. 
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e SCADA networking protocols, running directly over serial physical and data 
link layers. 


e At a high level, SCADA = systems collect sensor data and telemetry 
from remote devices, and to control them. 


e SCADA systems allow global, real-time, data-driven decisions to be made about 
how to improve business processes. 
e SCADA commonly uses certain protocols for communications between devices 
and applications. 
- Eg. 
» Modbus industrial protocols used to monitor and program remote devices via a 
master/slave relationship. 
» Modbus used in building management, transportation, and energy applications 


» TheDNPS (Distributed Network Protocol) and International Electrotechnical Commission 
(IEC) protocols are found mainly in the utilities industry, along with DLMS/COSEM 


» ANSI C12 for advanced meter reading (AMR). 


e These protocols used decade ago and are rial based. So, transporting them over 
current loT and traditional networks requires that certain Adjustments 
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» Ethemet and IP include the ability to leverage existing 
equipment and standards while integrating seamlessly 

the SCADA subnetworks to the corporate WAN 
infrastructures. 


- Assigning TCP/UDP to the protocols, as following: 
» DNPS (adopted by EEE 1815-2012) specifies the use of TCP or UDP on 
The Modbus messaging service utilizes TCP 
> IEC60870-5-104 isthe evolution of IEC60870-5-101 serial for running 
over Ethernet and IPv4 using port 2404. 


» DLMS User Association specified a communication profile based on TCP/IP 
in the DLMS/COSEM. 
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e Serial protocols have adapted and evolved to utilize IP and TCP/UDP as 
both networking and transport mechanisyrs. 


e DNP3 (Distributed Network Protocol) is based on a master/slave 
relationship. 

- The term master is refers to a powerful computer located in the control 
center of a utility, and a slave is a remote device with computing resources 
found in a location such as a substation. 

- DNPS refers to slaves as outstations. 

» Outstations monitor and collect data from devices that indicate their state, 
such as whether a circuit breaker is on or off, and take measurements, 
including voltage, current, temperature, and so on. 

- Ths data is then transmitted to the master when it is requested, or events or 
alarms and control commands can be sent in an asynchronous manner. 
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Figure 6-2 Protocol Stack for Transporting Serial DNP3 SCADA over IP 
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» Connection management links the DNPS layers with the IP layers 
in addition to the configuration parameters and methods 
necessary for implementing the network connection. 

- The master side initiates connections by performing a TCP active 
open. 

- The outstation listens for a connection request by performing a 
TOP passve open. 

- Master stations may parse multiple DNPS data link layer frames 
from a single UDP datagram, while DNP3 data link layer frames 
cannot span multiple UDP datagrams. 

> Single or multipole connections to the master may get established 
while a ICP keep alive timer monitors the status of the 
connection. 


lol Application Transport Methods SCADA - 
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e End-to-end native IP support is preferred, in the case of DNP3. 


e Otherwise, transport of the original serial protocol over IP can be 
achieved either by tunneling using raw sockets over TP or UDP or by 
installing an intermediate device that performs protocol translation 
between the serial protocol version and its IP implementation. 


- A raw socket connection simply denotes that the serial data is 
being packaged directly into a TCP or UDP transport. 
eA socket is a standard application programming interface (API) 


composed of an IP address and a T@ or UDP port that is used to 
access network devices over an IP network. 
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Scenario A: Raw Socket between Routers — no change on SCADA server 


» Scenarios A, Band C in Figure, 


» Routers connect via serial interfaces to the remote terminal units (RTUs), which are 
often associated with SCADA networks. 
- An RIU ‘ts a multipurpose device used to monitor and control various systems, applications, 
and devices managing automation. 
» From the master/slave perspective, the RTUsare the slaves. 
» Opposite the RTUsin is a SCADA server, or master, that varies its connection type. 


loT Application Transport Methods SCADA - 
Tumneling legacy SCADA over IP Networks 


Raw Socket Master and 
Client Set-Up on Routers 


{ Serial 
Interfaces a= 
Infrastructure =o i 


Application Communicates 
Through COM Ports 


RTUs 


Scenario A: Raw Socket between Routers — no change on SCADA server 


» Scenarios A: 
» Both the SCADA server and the RIUs have a direct serial connection to 
their respective routers. 
» The routers terminate the serial connections at both ends of the link and use 


raw socket encapsulation to transport the serial payload over the IP 
network. 
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Scenario B: Raw Socket between Router and SCADA Server — no SCADA application change 
on server but IP/Serial Redirector software and Ethernet interface to be added 


» Scenarios B: 


» Asmall change on the SCADA server sde. A piece of software Is installed 
on the SCADA server that maps the serial COM ports to IP ports. This 
software is commonly referred to as an |P/serial redirector. The IP/serial 
redirector in essence terminates the serial connection of the SCADA server 
and converts it to a TCP/IP port using a raw socket connection. 
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Raw Socket Master and Client Set-Up 
Between Routers and SCADA Server 
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Scenario C: Raw Socket between Router and SCADA Server — SCADA application knows 
how to directly communicate over a Raw Socket and Ethernet interface 
> Scenarios C: 


» The SCADA server supports native raw socket capability. 


» Unlike in Scenarios A and B, where a router or |P/serial redirector software 
has to map the SCADA server's serial ports to IP ports, in Scenario C the 
SCADA server has full IP support for raw socket connections. 


loT Application Transport Methods SCADA - 
SCADA Protocol Trandation 


» With protocol translation, the legacy serial protocol is translated 


to a corresponding IP version. 
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Figure 6-4 DNP3 Protocol Translation 
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SCADA Protocol Trandation 


» Figure shows two serially connected DNP3 RTUs and two master 
applications supporting DNPS over IP that control and pull data 
from the RTUs. 

- The loT gateway in this figure performs a protocol translation 
function that enables communication between the RTUs and 
servers, despite the fact that a serial connection is present on 
one side and an IP connection is used on the other. 


- By running protocol translation, the lol gateway connected to the 
RTUs is implementing a computing function close to the edge of 
the network. Adding computing functions close to the edge helps 
scale distributed intelligence in lol networks. 
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SCADA - SCADA Transport over LLNs with MAP-T 
- Due to the constrained nature of LLNs, the implementation of 
industrial protocols should at a minimum be done over UDP 
> This in turn requires that both the application servers and devices 
support and implement UDP 


» When deployed over LLN subnetworks that are IPv6 only, a 
transition mechanism, such as MAP-T (Mapping of Address and 
Port using Translation), needs to be implemented. 
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Kisure 6-5 DNP3 Protocol over 6LoWPAN Networks with MAP-T 
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- In figure shows a scenario in which a legacy endpoint is connected 
across an LLN running GBLOWFAN to an IP-capable SCADA server. 


» The legacy endpoint could be running various industrial and SCADA 
protocols, including DNP3/IP, Modbus/TCP, or IEC. 


° oe scenario, the legacy devices and the SCADA server support only 

° MAP-T makes the appropriate mappings between |IPv4 and the IPv6é 
protocols. 

- Ths allows legacy |IPv4 traffic to be forwarded across |Pv6 networks. 


- In Figure the IPv4 endpoint on the left side is connected to a Customer 
Premise Equipment (CPE) device. 
- The MAP-T CPE device has an IPv6 connection to the RF_mesh. 


» On the right side, a SCADA server with native IPv4 support connects to 
a MAP-T border gateway. 
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e The level of familiarity with generic web-based protocols is high. 


e Therefore, programmers with basic web programming skills can work on 
loT applications, and this may lead to innovative ways to deliver and 
handle real-time loT data. 

eOn non-constrained networks, such as Ethemet, Wi-Fi, or 
3G/4G cellular, where bandwidth is not perceived as a potential issue, 
data payloads based ona verbosedata model representation 

° In case of constrained networks the embedded web server 
software with advanced features are now implemented with very 
little memory (in the range of 10KB). 


Generic Web-Based Protocols 


e lol devices that only pushdata to an application may need to 
implement web services on the client side. 
- For example, 


> an Ethemet- or Wi-Fi-based weather station reporting data to a weather map 
application. 


> The HTTP client side only initiates connections and does not accept incoming 
ones. 


e Some loT devices, such as a video surveillance camera, may have web 
services implemented on the server side. 


e Interactions between real-time communication tools powering 


collaborative applications, such as voice and video, instant messaging, 
chat rooms, and loT devices, are also emerging. 


- Extensible Messaging and Presence Protocol (XMPP). 
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- When considering constrained networks and/or a large-scale 
deployment of constrained nodes, verbose web-based and data 
model protocols, may be too heavy for lol applications. 


- To address this problem, the new lightweight protocols that are 
better suted to large numbers of constrained nodes and 
networks. 


> Wo of the most popular protocols are 
> CoAP 
> MQTT 
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Figure 6-6 Example of a High-Level IoT Protocol Stack for CoAP and MQTT 
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> CoAP and MQITare at the top of this sample loT stack, based 


on an IEEF802.15.4 mesh network. 
» CoAP deployed over UDP and MQTT running over TCP 
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- Constrained Application Protocol (CoAP) 


> IS to develop a generic framework for resource-oriented applications 
targeting constrained nodes and networks. 

- The CoAP framework defines simple and flexible ways to manipulate 
sensors and actuators for data or device management. 

> The CoAP messaging model is primarily designed to facilitate the 
exchange of messages over UDP between endpoints, including the secure 
transport protocol Datagram Transport Layer Security (DTLS). 

» CoAP over Short Message Service (SMS) as defined in Open Mobile 
Alliance for Lightweight Machine-to-Machine (LWM2M) for lol device 
management. 
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- ACOAP message Is composed of 
- a short fixed-length Header field (4 bytes), 
» a variable-length but mandatory bken field (0-8 bytes), 


» Options fields if necessary, and the Payload field. 
4 Bytes 


11111111 Payload (Optional) 


Figure 6-7 CoAP Message Format 
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CoAP Message Field Description 
Ver (Version) Identifies the CoAP version. 


T (Type) Defines one of the following four message types: Confirmable 
(CON), Non-confirmable (NON), Acknowledgement (ACK), or Reset 
(RST). CON and ACK are highlighted in more detail in Figure 6-9. 


TKL (Token Length) Specifies the size (0-8 Bytes) of the Token field. 


Code Indicates the request method for a request message and a response 
code for a response message. For example, in Figure 6-9, GET is the 
request method, and 2.05 is the response code. For a complete list 
of values for this field, refer to RFC 7252. 


Message ID Detects message duplication and used to match ACK and RST 
message types to Con and NON message types. 


Token With a length specified by TKL, correlates requests and responses. 


Options Specifies option number, length, and option value. Capabilities 
provided by the Options field include specifying the target 
resource of a request and proxy functions. 


Payload Carries the CoAP application data. This field is optional, but when 
it is present, a single byte of all 1s (OxFF) precedes the payload. 
The purpose of this byte is to delineate the end of the Options 
field and the beginning of Payload. 


Table 6-1 CoAP Message Fields 
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» CoAP can run over |IPv4 or IPv6. However, it is recommended 
that the message fit within a single IP packet and UDP payload 
to avoid fragmentation. 
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HTTP-CoAP 
Proxy 


Figure 6-8 CoAP Communications in IoT Infrastructures 
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» CoAP communications across an lol infrastructure can take various 
paths. 


» Connections can be between devices located on the same or different 
constrained networks or between devices and generic Internet or cloud 
servers, all operating over IP 


» As both HTTP and CoAP are IP-based protocols, the proxy function 
can be located practically anywhere in the network, not necessarily at 
the border between constrained and non-constrained networks. 


» Just like HTTP CoAP is based on the RéST architecture, but with a 


“thing” acting as both the client and the server. 
» Through the exchange of asynchronous messages, a client requests an action via a 
method code on a server resource. 
» Auniform resource identifier (URI) localized on the server identifies this resource. 
» The server responds with a response code that may include a resource representation. 
- The CoAP request/response semantics include the methods GET, POST, PUT.and DA-_ETE 
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» Message Queuing Telemetry Transport (MQTT) : 

» Considering the harsh environments in the oil and gas industries, an 
extremely simple protocol with only a few options was designed, with 
considerations for constrained nodes, unreliable WAN backhaul 
communications, and bandwidth constraints with variable latencies. 

» These were some of the rationales for the selection of a client/server and 
publish/subscribe framework based on the TCP/IP architecture, 
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Figure 6-10 MQTT Publish/Subscribe Framework 
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e An MQIT client can act as a publisher to send data (or resource 
information) to an MQITserver acting as an MQIT message broker. 


> In Figure the MQITT client on the left side is a temperature (Temp) and 
relative humidity (RH) sensor that publishes its Temp/RH data. 
> The MQTT server (or message broker) accepts the network connection along with 
application messages, such as emp/RH data, from the publishers. 
» It also handles the subscription and unsubscription process and pushes the 
application data to MQTT clients acting as subscribers. 
> The application on the right side of Figure is an MQITT client that is a 
subscriber to the Temp/RH data being generated by the publisher or 
sensor on the left. 


- This model, where subscribers express a desire to receive information from 
publishers, is well Known. 
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MATT 


e The presence of a message broker in MQIT decouples the data 
transmission between clients acting as publishers and subscribers. 


- In fact, publishers and subscnbers do not even know (or need to know) 
about each other. 


> A benefit of having this decoupling is that the MQTT message broker 
ensures that information can be buffered and cached in case of network 
failures. 


e Compared to the CoAP message, MIQIT contains a smaller header of 2 
bytes compared to 4 bytes for CoAP. 
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Figure 6-11 MQTT Message Format 


ee 
lol Application layer Protocols 


MQITT 

» MQTT is a lightweight protocol because each control packet 
consists of a 2-byte fixed header with optional variable header 
fields and optional payload. 

» The first MQTT field in the header is Message Type, which 
identifies the kind of MQTT packet within a message. 
» Fourteen different types of control packets are specified in MQTT. 

- Each of them has a unique value that is coded into the Message 
Type field. 
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Message Type 
CONNECT 
CONNACK 
PUBLISH 


PUBACK 


PUBREC 


PUBREL 


PUBCOMP 


SUBSCRIBE 
SUBACK 
UNSUBSCRIBE 
UNSUBACK 
PINGREQ 
PINGRESP 
DISCONNECT 


Value 


10 
Il 
12 
13 
14 


Flow 
Client to server 
Server to client 


Client to server 
Server to client 


Client to server 
Server to client 


Client to server 
Server to client 


Client to server 
Server to client 


Client to server 
Server to client 


Client to server 
Server to client 
Client to server 
Server to client 
Client to server 
Server to client 


Client to server 


Description 
Request to connect 
Connect acknowledgement 


Publish message 


Publish acknowledgement 


Publish received 


Publish release 


Publish complete 


Subscribe request 

Subscribe acknowledgement 
Unsubscribe request 
Unsubscribe acknowledgement 
Ping request 

Ping response 


Client disconnecting 


Table 6-2 MQTT Message Types 
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e The next field in the MQIT header is DUP (Duplication Flag). 
» This flag, when set, allows the client to notate that the packet has been sent 
previously, but an acknowledgement was not received. 
e TheQoS header field allows for the selection of three different QoS 
levels. 


e The next field is the Retain flag. 
> Only found in a PUBLISHmessage, the Retain flag notifies the server to 
hold onto the message data. 


- Ths allows new subscribers to instantly receive the last known value without 
having to wait for the next update from the publisher. 


e The last mandatory field in the MQTT message header is 
Remaining Length. 
- This field specifies the number of bytes in the MQTT packet following this 
field. 
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» MQTT sessions between each client and server consist of four phases: 
session establishment, authentication, data exchange, and session 
termination. 


» Each client connecting to a server has a unique client ID, which allows 
the identification of the MQTT session between both parties. 

» When the server is delivering an application message to more than 
one client, each client is treated independently. 

» Subscriptions to resources generate SUBSCRIBESUBACK control 
packets, while unsubscription is performed through the exchange of 
UNSUBSCRIBE/UNSUBACK contro! packets 

» Graceful termination of a connection is done through a DISCONNECT 
control packet, which also offers the capability for a client to 
reconnect by re-sending its client ID to resume the operations. 


